2 Things:

• It was always the idea to move from telescope.path to plenary.path and @anott03 has done a lot of work in plenary.path and here move from telescope/path to plenary/path #473 I do not know why this PR was never finished, it was around that time when i took a break. So you would need to speak with him how everything should continue
• There is also this PR Consistent filepath display and code cleanup. #839 which simplifies the whole display path thing and would make this PR way simpler. So i wanna at least wait till this is done.

Otherwise yes cool idea thanks :)

@Conni2461 I don't really know what happened with #473 either - I ended up taking a bit of a break as well. If I'm not mistaken, it was before TJ refactored actions so there's likely some work to be done before we can merge it.

Ah, okay. I'll have a look at #473 and #839 🙂

fyi #839 is merged. This PR is unblocked. This would be a nice change :)

I think we're also still waiting on #473 before this PR can proceed.
Although that PR hasn't been active in nearly a month, so not sure what is best to do at this point.

Yeah i haven't received an answer. Hmm i am thinking of just finishing it. I think anott03 is a little bit frustrated with me. I haven't done the best job of helping with that PR.

If i have a evening of free time next week, i will spend it on 473. I dont wanna block stuff that is actually super cool :)

@l-kershaw apologies for blocking you so long with #473! It's merged now so this should be good to go (I think Conni had some minor fixes he wanted to make – just double check that those are done). Let me know if you ever want help or feedback with this!

@anott03 no worries at all! Developer time is a scarce resource in open source projects, and I appreciate all of the time you spent on #473 🙂

I've reimplemented the shorten_len option, but I'm not sure I'm happy with the way the user configures it.
Since #839 has implemented path_display as a sort of "flag list", we can't pass a length in with the option.
So the shorten_len is separate from the rest of the path_display stuff, which feels weird.

Does anyone have any thoughts on better ways to implement this option?

Does anyone have any thoughts on better ways to implement this option?

I'll back at my desk later tonight and I'll see if I can come up with any ideas then :)

For interface i have 2 thoughts. path_display = { "shorten", 2 } for example (so index after shorten is potential len) or path_display = { "shorten" } (still valid) + support for path_display = { shorten = { len = 2 } }.

Also I would prefer len to be always a number, so we dont need tonumber. The util shorthand can then only be Path:new(filename):shorten(len) because plenary accepts either nil or a number >= 1 and already does the assert https://github.com/nvim-lua/plenary.nvim/blob/8bae2c1fadc9ed5bfcfb5ecbd0c0c4d7d40cb974/lua/plenary/path.lua#L346-L352

Thoughts on both interface ideas? You can also always ask tj if you are stuck, he will then make the decision 😆

@Conni2461 I don't really like either of your suggested configuration methods, they both feel weird to me (not that my method is any better, mind you). There seem to be two contradictory goals with configuring this:

1. keeping all the configuration for how the path is displayed in the path_display object.
2. keeping the path_display object as some sort of "flag list" of strings.

I'm not sure what to do, since these goals don't seem compatible and I don't really know which one to sacrifice in favour of the other. @tjdevries do you have any thoughts on this?

Regarding the change to utils.path_shorten I agree that we should remove all of this logic from telescope as it is handled on the plenary side. However, since this basically amounts to utils.path_shorten being a straight wrapper (with no additional stuff) for Path:shorten, is it actually worth keeping utils.path_shorten in telescope at all?

A quick project wide search for path_shorten only yielded one result – it's definition – so I see no reason to keep the function there (and even if there were uses, I'd say we should switch those to plenary and remove it from utils).

We will keep the shorthand for now because we dont wanna break extensions, we can deprecate it later :)

In hindsight this path_display = { shorten = { len = 2 } } is stupid. We can also do this path_display = { shorten = 2 }.
I know that path_display is a list of strings but i kinda like to keep all the display path related stuff under one key and i am not saying remove the other version (list of strings)

Also we had a discussion here #961 where i said path_display could either be a table or a function(opts, path) so more advanced people have 100% control of the displaying

@Conni2461 I think that your path_display = { shorten = 2 } style is the best option so far.
I've implemented it and updated the docs accordingly. I also added a deprecation warning for utils.path_shorten.

I don't think there's a better way to deal with this option, so I'm happy to just keep it like this.

@Conni2461 @anott03 is there anything else you think I should change?